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1 Dynamic Modularity in Flexible^ Persistent Agents 
2 

3 The present invention relates to software agents and in 

4 particular to the dynamic deployment of functionality in 

5 software agents. 
6 

7 Agents represent a means of representing a user in the 

8 electronic world, bringing together all the various 

9 functions that the user wants to perform in that 

10 electronic world, including: 

11 • transient, anonymous presence of an online search; 

12 • persistent occasional presence of online shopping at a 

13 particular store; 

14 • persistent passive presence of directed marking; 

15 • persistent though temporary realtime presence in an 

16 online game; 

17 and many more . 
18 

19 US Patent Application Publication Number US2002062334 to 

20 Hewlett Packard Company, CO, USA, entitled "Dynamic 

21 Agents for Dynamic Service Provision" teaches of dynamic 

22 agents and a dynamic agent infrastructure that supports 

23 dynamic behaviour modification of agents. One key 
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1 limitation of the appxoacH presente<a is tiiat it refers to 

2 the dynamic deployment of agent behaviour,- However, for 

3 the system to work as described, that dynamically 

4 deployed behaviour must be predefined (so that individual 

5 programs can know what to expect from others). The term 

6 'dynamic' is thus misleading. The work could better be 

7 described as the dynamic deployment of statically defined 

8 behaviour. One problem with US2002062334 is that software 

9 engineering in the large, and in particular, multi-party 
and multi-site development is made much harder by the 

11 need to conform to a rigid, pre-specif ied sets of 

12 functionality. It v/ould be advantageous for new 

13 functionality to be definable dynamically, so that 

14 separate teams can worker more independently, thereby 

15 simplifying problem decomposition. 
16 

17 US2O02O62334 describes dynamic functionality in an agent. 

18 It does not decouple functionality and therefore does not 

19 support functionality that is not at least defined at 
agent start-up. It discloses that the dynamic agent's 

21 modifiable portion includes its data, knowledge and 

22 action programs, which determines its application 

23 specific capabilities. Thus the generic, fixed portion of 

24 a dynamic agent, together with its application programs, 

25 acts as an autonomous problem solver. This means that 

26 generic capabilities (such as reasoning) are fixed at the 

27 point of startup of an agent. For agents that persist 

28 over a long period (months and years, rather than hours 

29 or days) this means that it is impossible to introduce 

30 new, generic capabilities as they become available. 

31 • 

32 Also, US2002062334 does not explain how existing 

33 functionality might be replaced. Crucially, if demands 



20 
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1 are made of a carried action, and those demands pile up, 

2 and the carried action is then replaced, there is no way 

3 of co-ordinating the rescheduling of those demands for 

4 the new carried action. By having a specific component 

5 responsible for hand-over during update, it would become 

6 possible to queue these demands until the new 

7 functionality is in a position to handle them. 
8 

9 Agents represent individuals, and typically persist over 

10 long periods. It is thus a very real problem that adding 

11 new generic functionality and upgrading existing 

12 functionality in deployed systems should be prohibited. 

13 As a consequence, it would be advantageous to implement a 

14 method by which even the core, generic functionality can 

15 be replaced. A portion of the data of an agent may be 

16 retained, at the discretion of the update mechanism, to 

17 maintain coherence (so, for example, the beliefs of an 

18 agent may persist through an update of core 

19 functionality) . This would allow upgrading of deployed 

20 agents through a straightforward, scalable mechanism. 
21 

22 US2002062334 discloses that when multiple actions are 

23 carried by the same dynamic agent, they can exchange 

24 information through the object store of that dynamic 

25 agent. However, for a carried action to be able to use 

26 data from another module, it must be able to anticipate 

27 the availability and internal structure of that data. 

28 That is, it must have knowledge of the "interface" 

29 provided by that action. So for any two actions that 

30 might need to interact, they must (a) know that the other 

31 action is carried, (b) know enough about that action to 

32 know what data it can provide and in what format. In this 

33 way, any 'old' carried action will be unable to exploit 
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ttie functionality developed in 'new carried actions that 

was unanticipated at the time of the development of the 

3 'old* carried action. This is a clear theoretical 

4 problem that translates into a large practical problem in 

5 situations where agent systems are deployed on a wide 

6 basis, particularly if they are persistent, and subject 

7 to rigorous quality of service requirements (such that 

8 they can't simply be 'switched off for an upgrade), 
9 

10 A second problem, in a similar vein, is that old actions 

11 cannot know of the methods (i.e. published procedures) of 

12 a newer carried action. It is presumably for this reason, 

13 and because it is much more difficult to design all 

14 possible method interfaces on a system-wide basis at the 

15 outset, rather than because of its data interfaces, that 

16 the disclosed system does not support method calls 

17 between carried actions. This reduces the potential for 

18 synergistic interplay between carried actions, and can 

19 lead to requiring redundancy ( reimplement ing identical 

20 functionality in different carried actions) . 
21 

22 The problem is thus that one carried action cannot make a 

23 call upon the abilities of another. This violates key 

24 principles of modern programming practice aimed at code 

25 reuse and adaptation, by forcing modules to implement all 

26 the functionality that they will need, rather than 

27 utilising functionality they may know is already 

28 available within other modules in the agent. 
29 

30 
31 
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It is an object of the present invention to provide 
efficient dynamic changes of modules in an agent and • 
overcome at least some of the problems identified above. 

According to a first aspect of the present invention, 
there is provided an agent for representing a person's 
identity adapted to dock a dockable module, the dockable 
module comprising a method means for performing a 
function, wherein the agent further comprises an 
intermodule communication means for mapping a request 
from a requesting module to the method means in the 
dockable module. 

Preferably said method means is adapted to perform said 
function responsive to said request. 

Preferably said request from the requesting module 
comprises a label specifying a function and said method 
means in said dockable module corresponds to the 
specified function. 

Preferably said intermodule communication means comprises 
a store of labels and associated modules. 

Preferably said store of labels and associated modules is 
a table. 

Optionally said method means is adapted to perform the 
function of docking said dockable module with said agent. 

Optionally said method means is adapted to perform the 
function of registering a label with said intermodule 
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communx Celt. Ion mea.ns , the Xa.k>el specifying a function 

supported by said dockable module. 

Optionally said method means is adapted to perform the 
function of undocking said dockable module from an agent. 

Optionally said method means is adapted to perform the 
function of requesting the discarding of a label from the 
intermodule communication means, the label specifying a 
function supported by said dockable module. 

Optionally said method means is adapted to perform the 
function of updating said dockable module within said 
agent. 

According to a second aspect of the present invention, 
there is provided a method of deployment of a module in 
an agent comprising the steps of: 

receiving a request for deployment of said modules- 
maintaining registration information relating to a 
function supported by said module; and 
invoking said function. 

Preferably said step of maintaining registration 
information comprises maintaining a store of labels and 
associated modules, each label specifying a function 
supported by a module. 

Preferably said store of labels and associated modules is 
a table. 
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1 Preferably said step of maintaining registration 

2 information comprises the step of registering a label 

3 specifying a function supported by said module, 

4 This is a final step in the docking process. 
5 

6 Alternatively said module is a docked module and said 

7 step of maintaining registration information comprises 

8 the step of unregistering a label specifying a function 

9 supported by said docked module. 

10 This is a final step in the undocking process. 

11 Alternatively said module is a replacement module and 

12 said step of maintaining registration information 

13 comprises the steps of: 

14 • unregistering a label specifying a function 

15 supported by a docked module from said agent; and 

16 • registering a label specifying a function 

17 supported by said replacement module with said 

18 agent 

19 and said method further comprises the steps of: 

20 • storing information related to the state of said 

21 docked module; and 

22 • instantiating said replacement module using said 

23 stored information. 
24 
25 

26 Optionally, said step of maintaining registration 

27 information further comprises the step of queuing calls 

28 to the docked modules' registered labels, prior to the 

29 step of registering a label specifying a function 

30 supported by said replacement module. 
31 

32 Preferably, said function supported by said module is the 

33 method of deployment of said module. 



stored information. 
These constitute steps in the process of updating. 
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1 

2 According to a third aspect of the invention there is 

3 provided a computer program comprising program 

4 instructions for causing a computer to perform the 

5 method of claims 11 to 18. 
6 

7 In order to provide a better understanding of the present 

8 invention, an embodiment will now be described by way of 

9 example only and with reference to the accompanying 
10 Figures, in which: 

11 

12 Figure 1 illustrates, in schematic "form, an agent and a 

13 module in accordance with a preferred embodiment of the 

14 present invention; 
15 

16 Figure 2 illustrates, in schematic form, an overview of 

17 agentative representation in a multi-service environment; 
18 

19 Figure 3 illustrates, in schematic form, the process by 

20 which a label is resolved in accordance with a preferred 

21 embodiment of the present invention; 
22 

23 Figure 4 illustrates, in schematic form, module docking 

24 in accordance with the present invention; 
25 

26 Figure 5 illustrates, in schematic form, module updating 

27 in accordance with the present invention; 
28 

29 The inventions are an architecture and methods for 

30 dynamic deployment of modules in a software agent. 
31 

32 Although the embodiments of the invention described with 

33 reference to the drawings comprise computer apparatus and 
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1 processes performed in computer apparatus, the invention 

2 also extends to computer programs, particularly computer 

3 programs on or in a carrier, adapted for putting the 

4 invention into practice. The program may be in the form 

5 of source code, object code, a code of intermediate 

6 source and object code such as in partially compiled form 

7 suitable for use in the implementation of the processes 

8 according to the invention. The carrier may be any 

9 entity or device capable of carrying the program. 
10 

11 For example, the carrier may comprise a storage medium, 

12 such as ROM, for example a CD ROM or a semiconductor ROM, 

13 or a magnetic recording medium, for example, floppy disc 

14 or hard disc. Further, the carrier may be a 

15 transmissible carrier such as an electrical or optical 

16 signal which may be conveyed via electrical or optical 

17 cable or by radio or other means. 
18 

19 When the program is embodied in a signal which may be 

20 conveyed directly by a cable or other device or means, 

21 the carrier may be constituted by such cable or other 

22 device or means. 
23 

24 Alternatively, the carrier may be an integrated circuit 

25 in which the program is embedded, the integrated circuit 

26 being adapted for performing, or for use in the 

27 performance of, the relevant processes. 
28 

29 With reference to Figure 1, the architecture 100 of an 

30 agent according to the present invention is best 

31 visualised as including a torus. On the inside of the 

32 torus 102, a special module, the core module 104, 

33 attaches itself. On the outside of the torus, any number 
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1 o£ application specific modules 106, 108 may also become 

2 attached. The security and unity of the agent is also 

3 conceptually protected by a thin sphere 110 encompassing 

4 all the modules. The torus itself coordinates all 

5 communication between modules and between modules and 

6 core: this is the Inter Module Communication Layer 

7 (IMCL) . 
8 

9 The modular architecture is implemented as a class that 

10 defines a module, from which specific classes, 

11 corresponding to modules with specific functionality, can 

12 be derived, A module 112 is shown with its components 

13 depicted. The module contains a number of components for 

14 implementing functions: 

15 1. A docking method 114 that is called when the 

16 module is introduced to the agent and that describes 

17 the functionality provided by that module; 

2 . An undocking method 116 that is called when the 

19 module is required to detach itself from the agent 

20 and terminate; 

21 3. An update method 118 that is called when the 

22 module is to be updated with a new version; and 

23 4. A set of message handling method 120 for between- 

24 agent communication. 
25 

26 The docking method of a particular module provides the 

27 IMCL with a list of labels. The extensible set of these 
labels is consistent system-wide, functioning as the 

29 definition of the system's programming interface and is 

30 maintained centrally by the service provider. A 

31 particular module implements methods that match some 

32 (typically small) subset of all labels. On docking, a 

33 module informs the IMCL which labels it provides 
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1 functionality for. As each module docks, the IMCL builds 

2 a table 122 of labels against which are listed the names 

3 of the methods that provide the functionality and the 

4 names of the modules implementing those methods. 
5 

6 In some cases, the labels implemented by a particular 

7 newly docking module may already be implemented by 

8 methods extant in the agent. So for example functionality 

9 implemented by method x in module ml may mean that when 

10 ml docks in an agent, it needs to register the label f 

11 with the IMCL- But some other method, y, in some other 

12 module, m2, that is already docked, may also implement 

13 functionality f . Thus the IMCL would list functionality 

14 f has being implemented by m2.y. 
15 

16 In such situations, the IMCL adds the new label and 

17 associated method to its table, but also includes a 

18 priority ranking, applied to both the new and old methods 

19 that implement the functionality. This priority is 

20 determined on the basis of some algorithm. Recency is a 

21 good example, whereby newer methods are always given a 

22 higher priority, but there are many such algorithms. 
23 

24 In addition, a module's docking method calls functions • 

25 provided by the core's module management. These calls 

26 register information about the module with the core, 

27 including its name, provenance and labelled 

28 functionality. 
29 

30 A user interacts with the electronic world for a host of 

31 reasons in a wide variety of domains: entertainment, e- 

32 commerce, professional, and so on. The present invention 

33 provides a means of bringing together all of these tasks 



wo 2<M»5/U66873 



PCT/GB2(M)4/I>05459 



12 

a.n<3 doiaaxris, arwa. provid-ing a single point of contact for 

the user, and allowing the sharing of user data between 
these different application domains. This contact is the 
user's agent, both in the computer -science sense (where 
agent oriented programming has particular restrictions, 
techniques and approaches, and places particular demands 
on software) , and also in the intuitive sense of 
providing services of advocacy and representation. A 
user's agent is their permanent representative in the 
electronic world. Ideally, each user has exactly one 
agent, and a user's agent represents exactly one user (at 
the very least, such a relationship exists in a given 
context) . The overall picture is as in Figure 2. 

With reference to Figure 2, an overview of agentative 
representation in a multiservice environment is shown. 
The user 202 connects to their agent 206 at any time via 
any device (2G phones, multimedia mobile handsets, 
internet- capable hardware, etc.) in ways that are well 
known. The user agents 204 which represent users in the 
virtual world are shown. One user has a single agent 206 
representing him or her in all their interactions in the 
virtual world. The service agents 208 provide specific 
services to any agents that request them, or that the 
service agents themselves decide to service. Information 
exchange between user and service agents can be initiated 
from either end. Some service agents 210 encapsulatje 
existing legacy services (e.g., databases, Web Services 
and proprietary data handling systems) . Broker agents 
212 can mediate between a user and service agents. The 
user agents service agents and broker agents may be 
provided as a trusted service by a telecommunications 
operator . 
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An agent is a sof tvyrare entity with particular 
characteristics. We refer here to software processes that 
are: 

persistent (in that they continue to exist for an 
extended real time period, adapting to a single user over 
that time) ; 

proactive (in that they include not only reactive 
behaviour, but also independently determined behaviour) ; 
communicative (in that they communicate with other 
agents) ; and 

autonomous (in that they typically cannot be directly 
modified by outside agencies, but must instead be altered 
through coramunciation) . 

The user can communicate with his agent across 
heterogeneous networks from a variety of devices, 
including mobile handsets and internet clients. In 
addition, however, the framework of the present invention 
supports the transparent filtering of information 
according to the device to which it is being sent. Thus 
the components within an agent that initiate 
coimnunication with a user need not have any 
representation of the device type a user is employing. 
The content of the message is instead dynamically 
tailored to the user's device (e.g. summary text to an 
SMS-enabled mobile device, still pictures to a MMS- 
enabled mobile device, streaming video to broadband 
internet client platform, etc.). 

The core is responsible for tailoring information to the 
device that is known to currently be available to the 
user. Thus, tailoring happens independently of the 
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1 module calls, so tKat individual modules do not need to 

2 maintain device-specific information. 
3 

4 This filtering is achieved through a module-independent 

5 communication object that is filled in by individual 

6 modules when they need to communicate with the user- 

7 This object has subparts for different forms of media 

8 (text, picture, video, audio, etc.,). A module fills in 

9 as many of these subparts as it is able. The core then 

10 mediates the sending of that message to the user, by: 

11 (i) identifying which device the user is currently 

12 employing (using a combination of historical usage 



13 patterns, presence information, and most recent- 

14 communication data) ; 

15 (ii) mapping the device to a set of media types (so, 

16 e.g.^ an old phone can handle text, a newer device, 

17 pictures) ; 

18 further limiting the media types on the basis of user 

19 preferences, and what has been made available by the 

20 module; and 

21 initiating the delivery of the appropriate media from the 

22 user communication object constructed by the module, 
23 

24 In order to provide representation for a user, an agent 

25 must implement a range of functionality. This 

26 functionality is gathered together into the core module. 

27 Modules can safely make the assumption that the core is 

28 available for them to make calls upon. 



29 

30 The core contains a range of specific methods that 

31 implement particular components of functionality. These 

32 methods can be grouped together into functional groups. 

33 Thus the core can be subdivided into discrete areas of 
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1 functionality. Any module can make a call on any of the 

2 methods in any of the areas of the core's functionality 

3 via the IMCL. The core provides methods that provide 

4 functionality corresponding to a fixed set of labels 



5 concerned with generic agent activity. This functionality 

6 includes ; 

7 1. Belief management (including lookup and update) 

8 2. User profile management (including lookup and 

9 update) 

10 3. Agent-User communication 

11 4. Module Management 

12 S.Basic generic reasoning tools 

13 6 .Between- Agent Module-Module communication (BAMM) 

14 (send and receive) 



15 

16 The agent as a whole is a unitary autonomous software 

17 entity, and as such maintains a single, coherent set of 

18 tokens representing information about the world. 

19 This belief database is changed through the action of 

20 methods in the core. These methods implement core labels 

21 for belief update. Any module (including the core itself) 

22 . can make calls as described herein on these labels 
23^ through the IMCL. 

24 

25 Similarly, the belief database can be queried by any 

26 method through a call to a label mapped through the IMCL 

27 to core functionality. Thus a module can perform a lookup 

28 on the currently held beliefs by calling this label. 
29 

30 The user profile is a subset of the belief database, and 

31 includes information specific to the user across a range 

32 of domains. Again, the core implements labels 

33 corresponding to update and query to the user profile. 



wo 2«05/«6687 J PCT/G B2004/005459 

16 

1 

2 There is the potential for the core to update the user 

3 profile dynamically in response to user actions - that 

4 is, the agent could adapt to and learn the user's 

5 preferences as a result of repeated interaction. 
6 

7 User data (e.g., address; credit card details; age) and 

3 user preferences (e.g., policy on releasing credit card 

9 details; preference for aisle or window seat on planes; 

10 preferred DVD supplier) are stored in a local, private, 

11 secure database . Both user data and user preferences are 

12 extracted in three ways. First, through an explicit 

13 online interface that requests input on date of birth, or 

14 supports update to reflect change of address. Second, if 

15 the agent recognises information that it needs from the 

16 user, it can ask for it directly (e.g. asking a yes/no 

17 question by SMS) , Third, as the user interacts with 

18 services manually, the agent can intercept information 

19 either explicitly or implicitly. If the user answers a 

20 particular question from a particular online service, the 

21 agent may either store that answer for future use, or ask 

22 the user explicitly if such storage is appropriate or 

23 useful. When acting autonomously, the agent provides 

24 information that external service requires (and no more) , 

25 less anything that the user has placed a restriction on. 

26 Thus, for example, when interacting with an online 

27 newspaper, the newspaper provider may request user 

28 registration, but not demand it. In this case, the agent 

29 would provide no user information. Alternatively, when 

30 interacting with a book e-tailer, the e-tailer may 

31 require personal details including credit card data. If 

32 the user has instructed his or her agent not to give out 

33 credit card details without confirming it first, the 
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1 agent would halt interaction with that site until user 

2 confirmation was sought and agreed. 
3 

4 These components could be represented by the steps: 

5 1. Agent has goal of interacting with a service 

6 2 , Select required information from the user model 

7 (UM) (accesses the UM) 

8 3. Check that the user model permits all this 

9 information to be freely given (accesses the UM) 

10 If so, 

11 4. Information given to the service 

12 Otherwise 

13 5. Process the restriction (either by terminating, 

14 or by asking the user, or by performing some 

15 other action) 
16 

17 The core also includes a subsystem responsible for 

18 passing messages to, and receiving messages from the 

19 user. The user may connect to his or her agent through a 

20 nxamber of different channels; using a web browser on a 

21 PC, using a rich media mobile device (a Java phone, for 

22 example), using a high capacity mobile device (such as 

23 one that uses GPRS) , or using an older, limited media 

24 device (say that can only handle voice and SMS traffic) . 

25 The core implements labels that handle communication to 

26 and from such devices quite transparently: the calling 

27 module does not need to specify the different 

28 coranrunication types at all. 
29 

30 The mecuis by which one agent communicates with einother is 

31 Implemented in tUe core. Racher tlian supporting only 

32 agent-to-agent messages, the architecture is instead 

33 built around the idea that it is individual modules 
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1 within agents th.a.t communicate with one another (this is 

2 "between agent module-module" or BAiyiM conununication) . 

3 Thus a module with expertise in buying in a particular e- 

4 commerce institution will communicate with a module in 

5 another agent that has expertise in selling in that same 

6 e-commerce institution. The fact that those agents also 

7 happen to have modules with expertise in a range of other 

8 diverse applications has no impact upon the conversation 

9 between buyer and seller in this domain. It is thus 

10 modules that structure conversations. The individual 

11 utterances (or, more accurately, utterance types) that a 

12 module uses to construct a given conversation are common 

13 across the entire architecture. The sending and receiving 

14 of these individual utterances is co-ordinated by the 

15 core. 
16 

17 In this way, a module in an agent can conduct 

18 conversations tailored to the domain in which the module 

19 has competence. Though the conversation structure is 

20 tailored, the implementation of primitive sending and 

21 receiving is located in the core. This means that there 

22 needs to be only one language definition - the language 

23 that agents use for all communication. (If BAMM 

24 communication was implemented solely in modules, those 

25 modules would, by definition, use their own idiosyncratic 

26 languages, and therefore the number of languages would be 

27 proportional to the square of the number of module 

28 types.) As language design and verification is a labour 

29 intensive task, reducing the task by separating primitive 

30 semantics from conversation definition, and rendering the 

31 former once only in the core, saves a great deal of 

32 effort. 
33 
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1 The IMCL provides a small number of function calls, the 

2 most important of which is the call which effects Within- 

3 Agent Module-Module (WAMM) communication. When one module 

4 wants to call a method in another module (including a 

5 method provided by the core) it calls the IMCL's WAMM 

6 communication method, passing it a label. The IMCL then 

7 resolves that label by referring to its table of labels. 

8 

9 This means that one module need not know which other 

10 module in^lements the functionality of a given label. 

11 Indeed, a module can be implemented in such a way that it 

12 can attempt a call on some labelled functionality, but 

13 exhibits robustness in the event that no module is 

14 present that implements that functionality. (Consider, 

15 for example, module x that is, amongst other things, 

16 responsible for performing some exponentiation 

17 calculation. Module x has two ways of performing the 

18 calculation - doing it itself, slowly and laboriously 

19 using repeated addition, or by asking a specialised 



20 



module y that can do exponentiation quickly and 



21 efficiently. The problem is that x has no way of knowing 

22 whether or not y is installed. Thus x makes a call to the 

23 IMCL requesting exponentiation on a particular data set. 

24 If y is installed, the IMCL will pass the request to the 

25 appropriate method within y. If y is not installed, the 

26 IMCL will inform x that no module in^lements 

27 exponentiation and x can then follow the more laborious 

28 route of performing the calculation itself) . The process 

29 by which a label is resolved is summarised in Figure 3. 



30 

31 With reference to Figure 3, a module makes a call co 

32 label L 310. The IMCL looks up L in a label table 312. 

33 If L is not present 314, the IMCL returns "not found" 
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1 316. IfLis present, and. L does Have multiple 

2 resolutions 318, then the IMCL selects the highest 

3 priority resolution 320. Next the IMCL calls the method 

4 described in the resolution 322, Finally, when the 

5 method returns a value 324, the IMCL passes the return 

6 value back to the caller . 



8 A practical advcuitage of the approach is that it removes 

9 compile time dependencies: a module developer can design, 

10 implement and test a module which makes calls to another 

11 module that they do not have, or do not have access to, 

12 or, indeed, that has not been developed at all. This 

13 simplifies many of the problems of software engineering 

14 in the large, and of multi-site collaborative development 

15 work. 
16 

17 With reference to Figure 4, a flowchart 700 of the module 

18 docking process is shown. First, either a user specifies 

19 702 a module, the core receives a message 704 specifying 

20 a module to download, or the core determines 706 that a 

21 module should be downloaded. The core reasons and decides 

22 708 whether or not to download the module. If a download 

23 is determined to be completed, the core calls 710 the 

24 IMCL with the getmodule label and URI (Universal Resource 

25 Identifier) specifying the location of the Java Archive 

26 file (having the .jar file extension). If not, the 

27 docking process ends 730. The IMCL then resolves 712 the 

28 getmodule label to the ModuleManagement .ModuleGet method 

29 in Lhe core and the IMCL calls 714 the core's 

30 ModuleManagement .ModuleGet method with the URI. 

31 ModuleManagement downloads 716 the Java Archive file from 

32 the URI. The .jar manifest file 718 specifies the Module 

33 class and the Module class 720 includes the DockMe 
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1 method. With this information, the ModuleManagement 

2 instantiates 722 the Module class and calls 724 the 

3 DockMe method • The DockMe method may then register 726 

4 labels with the IMCL and initialise 728 the BAMM handler 

5 before ending the process 730. 



7 The undocking method of a particular module informs the 

8 IMCL and the core module management that the 

9 functionality provided by the module is terminating, and 
10 then kills the module's thread. 

11 

12 One of the advantages of decoupling of functionality in 

13 separate modules is in allowing modules to be added to an 

14 agent on- the fly- Such modules need not have 

15 functionality that is known before the agent is 

16 instantiated/ as each module describes its own behaviour 

17 and functionality on docking. The same approach can be 

18 used to update existing modules with new versions. 
19 
20 

21 removes compile time dependencies: a module developer can 

22 design, implement and test a module which makes calls to 

23 another module that they do not have^ or do not have 

24 access to, or, indeed, that has not been developed at 

25 all. This simplifies many of the problems of software 

26 engineering in the large, and of multi-site collaborative 

27 development work. 
28 

29 The core is responsible for the handling of new modules 

30 and module updates. It arrcinges for outgoing requests to 

31 be sent for new raoGules (or for updated versions of 

32 existing modules), handles incoming requests for the 

33 agent to take on new modules, and handles the process by 



Another, practical, advantage of the approach is that it 



At 
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which a. module is addea . So, for exisunple, if the us* 

decides to sign up for a new, free service, the core may 

3 send a message to the coordinating agent for that 

4 service, requesting the module. After some brief 

5 negotiation, the coordinating agent may send back a 

6 request to install the new module. The core module 

7 management accepts and downloads the software. After 

8 updating the internal module database, it starts the new 

9 module, which then docks with the IMCL, as described 
10 above. 
11 

12 The process of updating a module and the handover between 

13 the older and newer versions is illustrated in Figure 5. 

14 With reference to Figure 5, a flowchart 800 of the module 

15 updating process is shown. First, either a user specifies 

16 802 a module, the core receives a message 804 specifying 

17 a module to update, or the core .determines 806 that a 

18 module should be updated. The core reasons and decides 

19 808 whether or not to update the module. If an update is 

20 determined to be completed, the core calls 810 the IMCL 

21 with the getmodule label and URI specifying the location 

22 of the Java Archive file. If not, the updating process 

23 ends 836. The IMCL then resolves 812 updatemodule label 

24 to the ModuleManagement .ModuleUpdate method in the core 

25 and the IMCL calls 814 the core's 

26 ModuleManagement .ModuleGet method with the module name 

27 and the URI. ModuleManagement calls 816 the module's 

28 UpdateMe method and the UpdateMe method returns the 

29 module state information, which is then stored 818 by 

30 ModuleManagement. ModuleManagement downloads 820 the Java 

31 Archive file from the URI. The .jar manifest file 822 

32 specifies the Module class and the Module class 824 

33 includes the DockMe method. With this information, the 
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1 ModuleManagement instantiates 826 the Module class and 

2 calls 828 the DockMe method with the stored state 

3 information. The DockMe method may then register 830 

4 labels with the IMCL and initialise 832 the BAMM handler 

5 before the Module Management calls 834 the UnDockMe 

6 method on the old module and unloads the class then ends 

7 the process 836. 
8 

9 The core's module management also handles more complex 

10 situations, in which a new version of an existing module 

11 is installed. The handover between the modules requires 

12 careful timing to ensure service to the rest of the agent 

13 are not disrupted. When a new version of a module is to 

14 be docked, the core module management calls the old 

15 version's update method, and, at an appropriate moment 

16 (at a break between discrete tasks that the module is 

17 working on) the module returns a representation of its 

18 current state . 
19 

20 Then, as part of the new module's docking method, it 

21 accepts the state of the previous version's data, so that 

22 it can pick up from where the previous module left off. 
23 

24 During the handover between versions of a module, the 

25 IMCL queues calls to the modules' labels, awaiting the 

26 docking of the new version. 
27 

28 Some of the functionality described herein is collected 

29 together in the core. Rather than hardwire a distinction 

30 between core and other modules, the core is instead 

31 implemented in just the same way as any other raoaule. 

32 This means that calls on core functionality can exploit 
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tHe robustness of tKe label -t>asea, IMCL-meaiabea inetHoa 

calling. 

It also means that core itself can be updated and docked 
through just the same process as any other module (so the 
activity of the module management component in the old 
core is interrupted and then taken up by the activity of 
the module management component in the new core) . This 
means that new core functionality can be deployed 
d2/namically, without other modules needing to know ahead 
of time all that might be included. 

Agentative representation in mobile services represent a 
domain in which persistency is crucial, and quality of 
service requirements are extremely high (and in some 
cases, are at safety critical levels) , The present 
invention provides the capability to decouple modules in 
such a way that both data exchange and method calls can 
be executed without prior knowledge of anticipated 
functionality . 

In addition, agents can be enabled to be dynamically 
equipped with behaviours that had no definition at the 
time those agents were initiated. Furthermore the agents 
are provided with means for: (i) agent mediation of the 
update (that is agents communicate between themselves to 
arrange for update to functionality); (iii) dynamic 
update of core functionality in exactly the same way as 
any other module (because core should be treated in the 
same way as any other module) ; and (iv) the ability to 
replace existing functionality in a principled manner, as 
well as add to it. 
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1 Further modifications and improvements may be added 

2 without departing from the scope of the invention herein 

3 described. 
4 

5 



